inscatolati - Get out of the box! :)

On recent Linux kernels, tcpdump can listen on multiple interfaces.

In order to do so, just specify the 'any' virtual interface with something like:

# tcpdump -i any

When the 'any' interface parameter is specified, interfaces are not put into promiscuos mode.

To manually set interfaces into promiscuos mode, just use something like:

# ifconfig eth0 promisc

or

# ip link set eth0 promisc on

Note that we don't know any way to specify selectively a list of interfaces to listen on, and we don't know any way to have an indication of the name of the interface on which a given packet was captured.

A workaround could be the '-e' parameter, to have link-level headers dumped. Note, however, that link-level headers may easily be spoofed or just wrong.

Manually setting the MTU allows you to force the kernel to send smaller packets regardless of the media being used or protocols like Path MTU discovery or similar.

You can set the MTU either for a whole interface, using something like 'ifconfig eth0 mtu 200' or 'ip link set eth0 mtu 200', or for a single path with something like: 'ip route add 192.168.0.0/24 via 10.0.0.1 dev eth0 mtu 200'. In this case, you need to have the 'iproute2' package installed on your system.

You may as well change the 'advertised' MSS to ask remote ends to send you smaller or bigger packets. To change the mss for a single route, just use something like: 'ip route add 192.168.0.0/24 via 10.0.0.1 dev eth0 advmss 200' if you have the iproute2 package installed, or 'route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.0.1 mss 200'.

Ok, so you just wrote your wonderful daemon that listens on a given sockets and provides some nice service over the network?

With manual file descriptors handling (using open, write, read, ...) it is easy to make errors in handling buffers and network conditions correctly.

If you had reports about people not being able to use your software from certain internet locations, or you are ready to release a new version of your software, you should check the correct behavior of network related routines with different MTU and packet sizes. Small packets can easily trigger buffering errors, or make some of the assumptions you made about your code miserably fall over below your floor.

One easy way to check the behavior with different MTUs is just to set the loopback MTU to a different size, and then perform some tests on the application by connecting to 127.0.0.1.

To know more about how to set the MTU of an interface, please refer to http://notes.inscatolati.net/[en]/system[en]/networking[en]/index.html#15.

One easy way to have the list of ports open on a Linux box is to use the 'netstat -nlp' command, 'netstat -ntlp' just for TCP, or 'netstat -nulp' for just UDP, where:

-n

tells netstat not to resolve ip addresses/port numbers into hostnames/port names.

-l

tells netstat to show only sockets waiting for connections (in listen state).

-p

tells netstat to show the pid of the involved processes.

-t

tells netstat to show the pid of the involved processes.

Sometimes, however, netstat will not show the pid of a given process, and will show a '-' instead. That does not mean there is 'no process' associated with the listening socket, or that your box has been hacked as you can read on some messages on various mailing lists.

Most of the times, those ports have been opened by the linux kernel directly, and that is why 'there is no process' associated. Are you using khttpd? nfs? sun rpc? Most of the times, those ports are related to the 'portmapper' and protocols based on sun rpc. To see which ports are related to which service, supposing that rpc is the reason, you can use 'rpcinfo -p'. By running 'rpcinfo -p' on my notebook, I can see that port '2049', not bound to any process accordingly to 'netstat', is the 'nfs' server. By running 'ps aux', I can see that something like '[nfsd]' is running (kernel NFS daemon), and with 'lsmod' I can see that the 'nfsd' module is running. If I go to /proc/2839, which is the PID of the nfsd process, I can see that the 'exe' symlink does not point anywhere: a good indication that 'nfsd' is not a real program, but a component of the kernel itself.

By using:

# netstat -s

it is possible to obtain nice-looking general purpose networking statistics, like the number of tcp connections established, failed, the number of ip packets sent, the number of packets with bad checksums, the number of segments retransmitted, and so on...

On Windows 2000, if you boot the PC with your poor, simple, 56k modem turned off... you loose the ability to use the modem!!

Solutions: reinstall the driver of the modem, or simply reboot your pc with the modem turned on. This time, it will properly work...